To fully realize the possibilities of system-on-chip (SoC) design and not just fill the die with RAM, designers must define true, stable platforms and system-level design methods that allow fast mapping of a particular system on that platform, performance analysis, software implementation and fast derivative design. Although these platforms will be diverse, the underlying design methods must be common, and so must the interfaces.
The platform that a core processor vendor offers is by nature computation-centric, whereas the system integrator's platform in many cases may need to be communication-centric. The buses of first-generation SoC devices, even hierarchical buses, are not sufficient to define communication platforms. More intelligent, network-like platforms must emerge if engineers are to truly divide and conquer the enormous task of SoC design.
 |
|
The strongest arguments against a virtual socket interface standard in conjunction with on-chip bus-based architectures have been nonoptimal performance and cost. Those arguments will weaken significantly as SoC designers move to future communication-centric platforms that favor high total bandwidth over quick single-register access. In such a communication-centric platform, the hardware socket becomes part of the platform application-programming interface (API), just as the driver layer is an API for the software developer. The socket API must be there to provide the lexicon for the various computing and communication elements to talk to each other.
Ever since the Virtual Socket Interface Alliance (VSIA) coined the term in the late '90s, socketization of virtual components (VCs) has been widely recognized as a prerequisite for reuse. The VSIA broadly scoped the socket for VCs to include not only the logical and physical interfaces, but also the attributes required by the whole engineering process, i.e. design data formats, IP protection, transfer and quality.
Thanks to VSIA, the engineering process part of the virtual socket is rather well-understood. Hardware VC design, trading and reuse have become mainstream engineering practices. Although the commercial VC trade has yet to become a major business, VCs are an essential part of product development, and engineers must understand them from design, integration, sourcing and logistics points of view.
The part of the socket engineers miss most is the logical interface. VSIA's attempt at this, the VCI standard, was technically sound but failed to attract enough adopters to become ubiquitous. That happened because of the infancy of the VC business, fear for insufficient support and a perceived fight for the same ecological space with native on-chip bus interfaces.
On-chip buses and their native interfaces have been providing SoC integrators with sufficient socket-like features for the first-generation SoC architectures. Proprietary bus standards have guaranteed user and developer bases that are sufficiently large to support VC commerce, but reuse of VCs designed for one bus is difficult to accomplish within a system using another bus.
The first-generation SoC architectures were typically based on a processor core or two. Those architectures were often designed using a process much like a printed-circuit board constrained by the processor's and ASIC design's specifications, without consideration for the total system's terms. Although platform-based design principles were just beginning to take hold in those first SoC architectures, the methodology has yet to be fully exploited to boost time-to-market.
---In the communication-centric platform, the hardware socket becomes part of the platform application programming interface (API), just as the driver layer is an API for the software developer.
Anssi Haverinen chairs VSIA's On-Chip Bus working group and is a steering group member in the OCP-IP. With more than 10 years of experience in the industry, he now is a research manager at Nokia in Boston, where he has worked in EDA, ASIC design, embedded systems and SoC design and research.
http://www.isdmag.com
Copyright © 2002 CMP Media LLC
5/1/02, Issue # 14155, page 38.
